When a terminal A needs to connect to a remote unit of equipment B via a network, for example a connection across a public wide-area network (or WAN) such as the Internet network to a gateway for accessing a local-area network (or LAN), it is necessary for this terminal A to dispose of data for connection to this equipment B. In the case of an IP (Internet Protocol) connection, this connection data includes the public IP address and a open public communications port on the equipment. This connection data identifies the equipment B in a unique manner and allows a connection to be established with this equipment.
However, the public IP address of a gateway is potentially variable. The same is true for communications ports of this gateway that are open to the Internet network: the latter may be changed dynamically in order to respond to an issue of access security to this gateway from the network.
Obtaining connection data for a gateway currently assumes that use will be made of a domain name server C, referencing in an address book a domain name in association with an identification for the gateway and the public IP address allocated to this gateway, together with the communications port or ports opened by this gateway.
Obtaining connection data currently assumes that:
1) the gateway or the equipment B sends notifications to the server C for requesting the referencing of the equipment in the address book at each update by the equipment of its connection data,
2) the server C records the connection data in association with a referencing key comprising an identifier for the gateway,
3) the server supplies the terminal with the requested connection data, upon sending the referencing key used by the gateway.
The current solution has several limitations:                the connection data may be obtained by sending successive requests using automatically generated referencing keys, whether they are extracted from a dictionary or predicted on the basis of referencing keys previously allocated: it is therefore possible for this connection data to be obtained in a fraudulent manner;        the connection data being variable, the method by sending of successive requests is not appropriate because it must be iterated at each data update; the method may furthermore be doomed to fail when the connection data have been updated during this update phase.        
There thus turns out to be a need for making the mode of obtaining this connection data secure so that a third party cannot easily obtain it, notably not by successive trial and error tests.